Wrap cursor around viewport during G/R/S (#3255) - #4486

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/app_window/app_window_message_handler.rs, line 26:

<comment>On web, each locked `pointermove` reaches the editor through both the existing absolute path and this new relative path. The absolute update resets the position that the relative update advances, so G/R/S motion can cancel or jump; suppress normal pointer forwarding during software-cursor pointer lock, or use only one movement path.</comment>

<file context>
@@ -14,8 +14,16 @@ impl MessageHandler<AppWindowMessage, ()> for AppWindowMessageHandler {
+				// Also feed relative delta into InputPreprocessor for G/R/S infinite drag (fake cursor)
+				// Divide by viewport scale will be handled at source (desktop physical -> logical); here we keep raw
+				// but transform_layer will handle scaling via document_to_viewport
+				responses.add(InputPreprocessorMessage::RelativePointerMove { delta: glam::DVec2::new(x, y) });
 			}
 			AppWindowMessage::Close => {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/input_preprocessor/input_preprocessor_message_handler.rs, line 111:

<comment>The `RelativePointerMove` handler adds the raw physical-device pointer-lock delta directly to `self.mouse.position`, which is in viewport-logical coordinates used by the transform math. If the source (desktop `WindowPointerLockMove` / web `movementX`/`movementY`) does not divide the delta by the viewport/device-pixel scale before emitting it, G/R/S drag speed and distance will be wrong at non-1x HiDPI scale factors. The `AppWindowMessage::PointerLockMove` caller passes `x,y` verbatim with a comment saying the divide is handled at the source, but that contract is only enforced by the platform frontends; the editor-side handler here has no way to detect or correct a scaled delta. Confirm the scaling contract is actually applied (or normalize by `viewport.scale` here) so the accumulated viewport position stays consistent with regular `PointerMove` position updates.</comment>

<file context>
@@ -107,6 +107,11 @@ impl<'a> MessageHandler<InputPreprocessorMessage, InputPreprocessorMessageContex
 				responses.add(InputMapperMessage::WheelScroll);
 			}
+			InputPreprocessorMessage::RelativePointerMove { delta } => {
+				self.mouse.position += *delta;
+
+				responses.add(InputMapperMessage::PointerMove);
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At frontend/wrapper/src/editor_commands.rs, line 87:

<comment>The `app_window_pointer_unlock` editor command is never called from the frontend, so its generated `editor.appWindowPointerUnlock()` binding is dead code. Pointer unlock is handled instead by the transform layer directly emitting `AppWindowMessage::PointerUnlock` internally (`transform_layer_message_handler.rs`), so this JS-facing command has no caller. Remove it unless the frontend is intended to call it.</comment>

<file context>
@@ -84,6 +84,14 @@ mod editor_commands {
 		AppWindowMessage::PointerLock.into()
 	}
 
+	fn app_window_pointer_unlock() -> Message {
+		AppWindowMessage::PointerUnlock.into()
+	}
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At frontend/src/components/panels/Document.svelte, line 561:

<comment>On browsers requiring transient user activation, web G/R/S cannot acquire pointer lock because this request runs after `await tick()`. Handle the request synchronously from the initiating user event and abort the transform when the request rejects or emits `pointerlockerror`; otherwise the software cursor remains visible while no movement deltas arrive.</comment>

<file context>
@@ -520,6 +545,31 @@
+			// Browsers reject a re-lock request shortly after an unlock, so retry on each update
+			if (data.visible && viewport && window.document.pointerLockElement !== viewport) {
+				try {
+					viewport.requestPointerLock?.().catch(() => undefined);
+				} catch {
+					// Retried on the next update
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At desktop/src/app.rs, line 588:

<comment>When focus is lost during a native number-input drag, this releases the OS grab but does not notify `NumberInput` to run its drag cleanup. Native mode does not use browser pointer-lock events, and the synthesized Escape is sent only to the backend. Send an explicit frontend cancellation/unlock notification or otherwise invoke the native drag cleanup on focus loss.</comment>

<file context>
@@ -539,20 +570,22 @@ impl ApplicationHandler for App {
+			&& self.input_state.pointer_locked()
+		{
+			self.unlock_pointer();
+			self.send_cancel_escape();
 		}
 
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/transform_layer/transform_layer_message_handler.rs, line 543:

<comment>This software-cursor advance (delta accumulation, wrap, UpdateSoftwareCursor emit) is now duplicated verbatim in the PTZ-change branch and the main path. Extract it into a small helper (e.g. `fn update_software_cursor(&mut self, target: ViewportPosition, responses: &mut VecDeque<Message>)` that computes the delta from `self.mouse_position`) and call it from both paths so the two copies cannot drift apart again.</comment>

<file context>
@@ -540,6 +540,17 @@ impl MessageHandler<TransformLayerMessage, TransformLayerMessageContext<'_>> for
 				let old_ptz = self.ptz;
 				self.ptz = document.document_ptz;
 				if old_ptz != self.ptz {
+					if self.software_cursor_active {
+						let delta = mouse_position - self.mouse_position;
+						self.software_cursor_pos += delta;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/messages/tool/transform_layer/transform_layer_message_handler.rs, line 543:

<comment>When PTZ changes mid-gesture (e.g., wheel-zoom while dragging), this branch moves the software cursor by `delta` but the early `return` skips the G/R/S arms, so the object never gets that `delta`. The cursor (and the final hand-off of the grab) then stays offset from the transformed layer by the dropped deltas. Since the pre-existing code dropped the delta entirely on PTZ change, it either needs to apply the delta to the G/R/S operation as well (moving the return to after the transform arms), or not move the cursor here — otherwise the two paths diverge.</comment>

<file context>
@@ -540,6 +540,17 @@ impl MessageHandler<TransformLayerMessage, TransformLayerMessageContext<'_>> for
 				let old_ptz = self.ptz;
 				self.ptz = document.document_ptz;
 				if old_ptz != self.ptz {
+					if self.software_cursor_active {
+						let delta = mouse_position - self.mouse_position;
+						self.software_cursor_pos += delta;
</file context>